1. Field of the Invention
The present invention relates to the field of integrated circuit testing. More particularly, the present invention relates to the field of test shells for protecting proprietary information contained within ASIC cores.
2. Description of the Related Art
Application specific integrated circuits (ASICs) are full custom or semicustom microcircuits. Typically, the ASIC vendor supplies to the customer (ASIC designer) an ASIC library containing small scale functional blocks (primitives) as well as large scale functional blocks (cores). The customer then designs an ASIC to its own specification using these primitives and cores as building blocks. Depending on the software tools used by the customer, the customer may either work with these modules as individual building blocks using schematic capture techniques, or the customer may specify the circuit using a descriptive language such as VHDL or Verilog. In the latter case, a synthesis tool receives the descriptive language input, and synthesizes a circuit netlist that will implement the functionality specified by the customer. ASICs may also be designed using a combination of schematic capture and synthesis methods.
Cores may range in size up to extremely large functional blocks such as a mini Reduced Instruction Set Computer (RISC) processor. As integration levels rise, customers demand cores with greater functionality with which to implement their designs. The detailed design of large cores is usually considered proprietary information. Because it is desirable to maintain the detailed design of the core as proprietary information, it is desirable that the customer be given only the functional description and input/output timing diagrams of the cores so that he can use them in his design, and not be given the detailed design of the cores. Accordingly, the customer is supplied with a synthesis shell, which is a high level description of the implementation of the core, containing enough information for optimization to the synthesis tool regarding the core. The customer is also provided with a timing shell, which contains the input/output timing specifications of the core. Beyond these two shells, the customer does not need to know the detailed implementation of the core. Accordingly, the customer is not provided with internal design details.
After the ASIC has been designed and manufactured, the chip must be tested for any manufacturing defects. This involves first simulating the ASIC using a variety of input test patterns, and recording the simulation output results which represent the expected outputs of a properly functioning ASIC. The input test patterns are then applied to the actual ASIC. The actual outputs are compared to the expected outputs. Deviations from the expected outputs indicate that the ASIC has a manufacturing defect.
Logic buried deep within the ASIC may require an enormous number of test patterns to test. To facilitate testing, scan cells are added to the ASIC at strategic locations. Scan cells are points at which logic values may be forced into the ASIC (scan writable gates) and/or observed within the ASIC (scan readable gates). Scan cells normally take the form of flip-flops which may be forced to the desired logic level, and which may be read from outside the ASIC. In general, existing flip-flops are converted into scan flip-flops by adding some additional logic gates. For example, scan cells enable the tester to preset a counter within the ASIC to a particular count, and to verify that combinatorial logic derived from the counter outputs is working properly. Strategic placement of scan cells within an ASIC allows the number of test patterns required to fully test an ASIC to be drastically reduced. This is important primarily because the computer simulations necessary to produce the test patterns and expected resulting outputs require a great deal of computer resources. Without scan cell techniques, simulation times to produce test patterns that adequately test an ASIC would be impractically long. Furthermore, without scan cells some gates within an ASIC may be simply not testable. However, using scan cells it is possible to develop test patterns that will detect 99% or more of possible gate failures using a set of test patterns that is not impractically long. The fault coverage obtained is the percentage of possible gate failures that will be detected by a given set of test patterns. Scan cells are normally connected in long chains, allowing all of the scan cells to be written to or read from using only a few dedicated test I/O lines on the ASIC.
ASIC designs using embedded cores present a challenge to test. FIG. 1 illustrates the use of embedded core logic within an ASIC 100. Core 102 is a high level functional block designed by the ASIC vendor, and available to the customer as a library component. Core 102 receives inputs from some logic 104 and produces outputs used by some other logic 106. Embedded cores typically are supplied by the vendor along with a set of test patterns which, if applied in isolation, will produce 99% fault coverage. However, these patterns cannot usually be applied to the embedded core in isolation, because the core is buried inside the ASIC with no direct access to the core's primary inputs and primary outputs. Hence it is not possible to apply the supplied set of test patterns to the core in isolation unless some mechanism is supplied for accessing the core.
Among the isolation schemes that have been proposed are multiplexed isolation, boundary scan wrapped around the core, or test protocol expansion used for macro testing. All of these proposed techniques result in area and performance overhead, which may make these technique unacceptable for many applications.
A second possible type of approach is to generate new test vectors which will be applied at the ASIC level. Test pattern generation software is well known in the art, and is usually provided by third party vendors. The input to a test pattern generation program is typically a flattened ASIC netlist. The flattened netlist describes the complete ASIC in terms of primitives such as AND and OR gates, and their functional interconnections. The netlist is described as flattened because the cores, which are hierarchical functional blocks, have been reduced to their constituent primitives and interconnections. Using the flattened netlist, the test pattern generation software is able to generate test patterns that will test the ASIC with an extremely high percentage of fault coverage.
The problem with which the present invention is concerned is that supplying a flattened netlist to the customer from which the third party's test pattern generator software can generate test patterns to test the entire ASIC, conflicts with the goal of keeping the detailed design of cores confidential. The flattened netlist for the core comprises much of the proprietary design details that the ASIC vendor desires to keep confidential.